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Description 

BACKGROUND OF THE INVENTION 

[0001] The present invention relates to automated 
systems for monitoring real-time events for anomalies, 
recurring events specified activities and the like. More 
specifically, the present invention relates to a system for 
receiving input information from a plurality of sources, 
processing that information according to preset, defina- 
ble rules, determining if the collected data satisfies or 
violates the parameters of the operational rules and ex- 
ecuting appropriate response. 

SUMMARY OF THE INVENTION 

[0002] The system of the present invention is divided 
into three tiers: data gathering, processing and operator 
interface. Although the three tiers are interrelated to 
form the system, each of the three tiers can be inde- 
pendently modified while maintaining the integrity of the 
system. 

[0003] A number of data gathering units are distribut- 
ed throughout the system for information collection. The 
collected information is then processed according to a 
set of precessing rules. The rules can include automat- 
ed response to certain data and presentation of other 
data within defined parameters to one or more operators 
for further processing and/or response. The data gath- 
ering units can include remote units, indirectly or inter- 
mittently connected to the system, networked units, lo- 
cal units connected directly to the system and other data 
gathering units. The data collection units can communi- 
cate over wireless or land line communication channels. 
Communication of information can include dial up on 
POTS lines with transmission of information in packet 
data, VOA, audio, DTMF tones or other viable data 
transmission means. 

[0004] The processing is performed on one or more 
servers distributed throughout the system. The servers 
are linked to share data from a common data base and 
to execute rules processing according to a common rule 
set. Information collected is distributed throughout the 
system according to specified distribution rules for ef- 
fective processing and response. 
[0005] The information is gathered, handled and pro- 
vided to the system in a common communication data 
format defined by the system. The data so gathered rep- 
resents events which are then processed by the system 
according to a set of rules. The rules are executed on a 
tier separate from that of the data gathering and han- 
dling. The data is first processed on a automatic level, 
recognizing and responding to anticipated events. If a 
communicated event needs specific operator interven- 
tion, the system provides information of that event to a 
operator for appropriate direction and response. The 
system also monitors for specific events which are an- 
ticipated to occur at specified times. Failure to detect 



such an anticipated event can result in an automated 
active polling to determine the nature of the failure. Con- 
tinued failure to detect can result in an alert to initiate 
operator intervention. 

5 [0006] The present invention uses a scalable, three- 
tier client/server system using a component object Mod- 
el. The system can be deployed in a 32 bit Windows 
environment. All screen input allows for easy interna- 
tionalization, either through the use of graphical labels 

10 or table/header defined variables. Scalability ideally per- 
mits the system and/or at least substantial components 
of the system to operate on a single Windows 95 ma- 
chine for small installations, and large distributed net- 
works for big installations. The system permits scalabil- 

15 ity simply by changing deployment strategies. 

[0007] A three-tier system with COM components 
separates the operator interface, business rules, and 
data gathering/handling into separate logical compo- 
nents, potentially written with different applications. The 

20 MS Visual Studio is ideal for this as the contained appli- 
cations are designed for development of COM compo- 
nents and for the use and development of ActiveX. 
[0008] The true three-tier system permits use of any 
number of ODBC compliant databases. These includes 

25 MS FoxPro, MS Visual FoxPro, MS Access, SQL Serv- 
er, Oracle, dBase and others. 

Three Tiers: 

30 [0009] The three tiers are the User Interface (Ul), 
Business Rules Processing, and Database Gathering/ 
Storage and Handling. The present invention is de- 
scribed in a first embodiment below as a system for 
monitoring the location, movement and related activities 

35 of a population of individuals. The system is designed 
in such a way as to permit interchangeability of the var- 
ious components at each tier. The User Interface need 
not be the one developed for this invention, it could be 
a standard browser or other front end that suits the re- 

40 gional or language requirements of the end user. The 
Database Storage tier can be any ODBC compliant da- 
tabase structured to contain the basic information com- 
ponents used by the system. This permits relatively 
easy regionalization and scalability. The components of 

45 each tier of the present invention are as follows: 

TIER I: User Interface 

[0010] The user interface includes a number of com- 
50 ponents for display of desired information to the system 
operators and to allow access t the database and to pro- 
vide a user-friendly interface for manipulation of the data 
and for implementation of desired response to the data 
presented to the operator. The exemplary operator in- 
55 terface described below includes the following compo- 
nents: 

A. Data Entry/Edit Forms 
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Tabbed forms with name on each page 
Common navigation buttons with graphical labels 
Search on multiple fields and/or grid style incremen- 
tal 

search 

Simple presentation with logical groupings and a 
minimum of mandatory fields 

B. Incident Handling Screens 
Explorer style ordering 
Auto Dialer for follow-up 

C. Report Generation Screens 

Data driven report menus allow users to specify 
the unique suite of reports that they will use in their 
operation. In addition, the report engine permits 
more advanced users to develop their own reports 
and fit them into the system without necessitating 
access to the system source code. 

The document creation/delivery system per- 
mits the user to generate reports to a printer or disk 
file. Reports sent to the disk can be viewed on the 
screen or transmitted to another via facsimile or e- 
mail. 

D. Training and Testing Mode 

Training mode permits new and experienced 
users to hone their monitoring skills without affect- 
ing any real time data. Setting a flag in the local ma- 
chine's system registry forces entry into training 
mode. In addition, an on line test can be adminis- 
tered to trainees to determine skill levels and profi- 
ciency. The test questions can be devised by ad- 
ministration and scored automatically by the sys- 
tem. Scores can be kept in an operator file and can 
be used to inform the skills based routing of inci- 
dents. 

E. Remote Access Mode 

Remote access mode is a custom interface for 
users dialing into the system from a remote location. 
This may be accomplished using any of a number 
of remote control applications, or ultimately on a 
web site via the Internet. Remote access requires 
password identification and presents the remote us- 
er with a subset of data (generally related to their 
caseload) and a subset of the functions available to 
local users. 

TIER II: Business Rules 

[001 1] The business rules tier is the basic engine that 
determines how the system operates. 

A. Communication Server Clients 

[0012] Communication Server clients (ComServers) 
handle all communication with specific brands of Data 



acquisition equipment. The ComServer is designed to 
watch communication ports, which are assigned to a 
brand of equipment, and pass a normalized data "slug" 
to the database server for interpretation. ComServers 

5 provide a level of hardware abstraction for the database 
server by pre-processing information and passing it to 
the database by executing a method in the server. Typ- 
ically, Data acquisition equipment calling in first identi- 
fies itself by unit number. As soon as the ComServer 

10 receives the identity block it executes the Early Warning 
method on the database server and passes a port ID 
and unit identification. The ComServer then continues 
to receive event information from the Data acquisition 
equipment. When the ComServer has received all 

15 events, it executes the Event Received method of the 
database server and passes the entire normalized slug. 
After the database server processes and stores all in- 
formation, it executes the ComServer's DataSecure 
method and passes any kiss-off instructions to be sent 

20 to the Data acquisition equipment. 

[0013] This process of two-way communication be- 
tween the ComServer and database server serves sev- 
eral functions. First, because the database server re- 
ceives an "early warning" that the ComServer has a spe- 

25 cific unit on the line, the database server can begin to 
query the database and construct objects relevant to the 
owner of this particular unit. Second, the Data acquisi- 
tion equipment is not "kissed off" by the ComServer until 
such time as it receives notification from the database 

30 server that the events have been processed and stored. 
Failure to get a kiss off from the ComServer will cause 
the Data acquisition equipment to call back and repeat 
the message. Finally, by using a pre-defined interface 
between ComServer and database server only one of 

35 the components has to be written specifically for a dif- 
ferent brand of equipment. The ComServer handles dif- 
ferences between communication methods (modem, 
DTMF, flat file transfer, etc.) with the database server 
remaining essentially unchanged. 

40 

B. Database Server 

[0014] The database server is the primary shared 
component in the middle tier. It is this component that is 

45 responsible for interpreting messages received from dif- 
ferent ComServers into a common set of event codes, 
corrected (if necessary) for time zone and clock drift, 
and placed into the appropriate data storage tables. 
Similarly it processes timed out gatekeeper events and 

so manages activation and clearing of violations upon the 
prompting of the violation service. The database server 
handles all data updates for components in the middle 
tier. 

[0015] The database server is initiated by other mid- 
55 die tier or user interface components, and is never 
launched on its own. The database server contains sev- 
eral class libraries that define objects common through- 
out the application. These objects are described in latter 
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detail. 

[0016] While some of these objects (e.g. monitored 
individual, curfew, and the like) will remain fairly con- 
stant in different implementations of the system, other 
objects such as Slug, Last Message, and Event, may 5 
change based on the characteristics and features of the 
equipment being monitored. 

Violation Service 

[0017] The violation service determines when an in- 
cident should be presented as an alarm for follow up. 
All events processed by the data collection services that 
may be considered for processing as an alarm are 
placed into the violation service's table. The violation 
service then checks each potential alarm against a rules 
table to determine how that incident is to be treated. 
[0018] The rules table allows local administrators to 
define specific rules based on five hierarchical levels 
from default handling to the specific monitored individ- 
ual. The violation service can determine when an inci- 
dent should be "activated" for operator processing. If a 
"clearing event" is defined and occurs within the speci- 
fied time period, the violation service will clear both 
events. The violation service can also be directed to pre- 
pare incidents for follow-up by printing, faxing, or pag- 
ing. 

Gatekeeper Service 

[001 9] The gatekeeper service provides alarm gener- 
ation on events that are the result of NOT receiving an 
event from specific Data acquisition equipment. Such 
events include OUT PAST A SET TIME, MISSING SAN- 
ITY CHECKS, and FAILURE TO LEAVE AT A SET 
TIME. Since each of these events are based on variable 
schedules (curfew schedules or sanity call intervals) the 
host computer must handle them. 
[0020] In one exemplary embodiment, gatekeeper 
methods required checking for these events by period- 
ically polling the last message table for each registered 
Data acquisition equipment type. Each table was polled 
separately for each type of event, often resulting in mul- 
tiple polling. This strategy has the disadvantage of re- 
quiring processor overhead, especially in installations 
with very large caseloads of monitored individuals. 
[0021] The system of a second exemplary embodi- 
ment of the present invention avoids periodic polling. 
This will increase scalability by not having to dedicate a 
processor to this periodic polling. The gatekeeper is a 
communication server that monitors timer events rather 
than communication ports. 

[0022] The gatekeeper of the present invention utiliz- 
es the services of the watchdog timer service, described 
below, to alert it when a gatekeeper event occurs. When 
the watchdog times out a gatekeeper event, it notifies 
the gatekeeper service when then executes a method 
in its associated instance of the database server to proc- 



ess the gatekeeper events. 

[0023] The gatekeeper service is also referenced by 
instances of the database server that are initiated by 
communication server clients. The database server will 
execute a method in the gatekeeper service indicating 
the delta minutes until the next status (e.g. curfew or 
sanity) event for the Data acquisition equipment that it 
just serviced. If this time is earlier than the one that the 
gatekeeper has stored for this system, the gatekeeper 
will call the watchdog timer service and update it accord- 
ingly. If the time is later, the gatekeeper will not pass any 
new information to the watchdog timer service. 

Watchdog Timer Service 

[0024] The watchdog timer service is another impor- 
tant shared component in the middle tier. The sole func- 
tion of the watchdog timer service is to keep a list of 
registered processes and the time that they are sup- 
posed to be executed. Only one timer need be set for 
the process at the top of the list. If this timer expires the 
appropriate process is notified. The watchdog timer 
service does not execute any methods in other COM/ 
DCOM components other than to notify that a process 
has timed out. In this way, the same watchdog timer 
service can easily service numerous components with- 
out undue processor overhead and without getting 
bogged down with any one component. 
[0025] There are two types of watchdog events: a 
watchdog monitor and a watchdog timer. They differ on- 
ly in the component to be notified when the event times 
out. A watchdog monitor notifies any and all component 
objects registered with the watchdog as a monitor, while 
a watchdog timer notifies only the component object that 
set the timer. 

[0026] The watchdog monitor is used to keep track of 
the proper operation of any unattended service. For ex- 
ample, each ComServer will register with the watchdog 
timer service with both a Ping Interval and a Line Interval 
(values for each are maintained in the system registry). 
The ping interval describes the number of minutes that 
the ComServer must " ping" the watchdog to verify that 
it is alive. This is often referred to as a " heartbeat" . If 
the ComServer fails to respond with a " heartbeat" within 
the described interval, all registered watchdog monitors 
(such as a supervisor's workstation) will be notified and 
corrective action (such as checking the ComServer 
computer) is suggested. The line interval describes the 
number of minutes within which a call is anticipated from 
the monitoring equipment. This number varies with the 
caseload of monitored units as is recalculated by the da- 
tabase server with each call received. Every time a 
ComServer receives an event from an Data acquisition 
equipment the watchdog is fed with the appropriate line 
interval. If the line timer is triggered, all registered watch- 
dog monitors are notified and corrective action (such as 
checking the phone lines) is suggested. 
[0027] The watchdog timer is used to notify other 
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component objects that certain processes are to be in- 
itiated. Components requiring the use of the watchdog 
timer register with the watchdog and pass a process ID 
and number of minutes for the timer. When this time ex- 
pires the watchdog executes the notify method in the 
registered component. As described above, the gate- 
keeper service makes extensive use of this timer. 

F. Routing of Incidents 

Skills based routing 
Least activity routing 
Same operator routing 

G. Action Taken 

Call to monitored individual 

H. Follow-up and Notification 

Notification handling rules 
Notification method 
Notification days and times 

I. Random Contact 

J. E-Mail and Facsimile Service 
K. Voice Service 

L. Backup and Off Site Monitoring Service 
M. Security and Auditing Service 

[0028] The security and auditing service is a middle 
tier component which in initiated when a user logs into 
the system. The base security object contains default 
permissions available to any user and can be queried 
whenever the user attempts to perform a restricted op- 
eration. Maintaining a separate security object allows 
system security to be defined and modified without al- 
tering any other components. Individual users or groups 
of users can be given specific permissions beyond the 
default. 

[0029] The auditing service keeps track of changes 
made to the database by users. It is contained in the 
security object since each query to the security object 
which results in granting a user specific permission will 
also result in an entry in the audit table. 
[0030] For each different type of equipment moni- 
tored, a sub-class of the base class is created with basic 
properties set to describe the current equipment and 
custom methods created, or base methods amended, 
to accommodate the features of the equipment. This ob- 
ject oriented design not only permits easy adoption of 
new features and equipment types into the system, but 
also makes maintenance and upgrades less complicat- 
ed as adjustments to base classes are automatically in- 
herited by child classes. Careful design of the methods 
and properties for each class allow developers to make 
changes at only one level in the object hierarchy. 



BRIEF DESCRIPTION OF THE DRAWINGS 

[0031] For a better understanding of the nature of the 
present invention, reference is had to the following fig- 
5 ures and detailed description, wherein like elements are 
accorded like reference numerals, and wherein: 

Figure 1 is an exemplary system block functional 
diagram generally illustrating the three tiers. 

10 Figure 2 is an exemplary block diagram of the in- 
teraction on the User interface tier . 
Figure 3 is an exemplary block diagram of data 
routing between tier two and tier one. 
Figure 4 is an exemplary block diagram illustrating 

15 the data acquisition of tier three and the data flow 
between tier three and tier two. 
Figure 5 is an exemplary overall diagram of the 
three tiers. 

20 DETAILED DESCRIPTION OF PREFERRED 
EXEMPLARY EMBODIMENTS 

Three TIERS 

[0032] The three tiers are Operator Interface, Rules 
Processing, and Database Gathering/Handling. The 
present invention is described in a first embodiment be- 
low as a system for monitoring the location, movement 
and related activities of a population of individuals. The 
components of each tier of the present invention are as 
follows: 

TIER I: Operator Interface 

[0033] The operator interface includes a number of 
components for display of desired information to the 
system operators and to allow access to the data base 
and to provide a user friendly interface for manipulation 
of the data and for implementation of desired response 
to the data presented to the operator. The exemplary 
operator interface described below includes the follow- 
ing components: 

Data entry/edit screens 
Tabbed forms with name on each page 
Common navigation buttons with graphical labels 
Search on any field and/or grid style incremental 
search 

Simple presentation with logical groupings - mini- 
mum of forced 

fields and controls 
Incident handling screens 
Explorer style ordering 
Auto dialer 

Report generation screens 
Data driven report menu 
Document creation/delivery system 
Training and testing mode 
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[0034] In the training and test mode, operators are 
taken through an on-line training test. The results of the 
test are used to determine the assignment of tasks to 
individual operators. Test questions can be devised by 
administration, and scored. Scores can be kept in an 5 
operator file. These scores can be used to inform the 
skills based routing of the Rule Processing tier of the 
system. 

[0035] The system includes a messaging system for 
exchange of messages and information between open- 10 
ators and/or the system. 

TIER II: Business Rules 

[0036] The rules based processing tier of the system 15 
includes a set of rules for the processing the data gath- 
ered by the data gathering tier of the system. The sys- 
tem includes rules for processing the data based on 
standard responses to anticipated data and flexible re- 
sponses to data based upon expert or knowledge based 20 
programming and/or operator intervention or operator 
directed responses. The responses can include further 
data queries, actions taken to assess the status of mon- 
itored individuals, or other appropriate actions. 
[0037] In the exemplary embodiment, some of the fol- 25 
lowing incident handling rules can be included: 

Skills based routing of violations: 

Monitoring operators can be graded on skill lev- 
els based on experience, knowledge of particular 30 
customers needs, or other indices and have inci- 
dents routed to their station much like tech support 
lines route questions to operators. These would be 
stored in the security object at log on. 
Least activity routing: 35 

Prioritization of incidents can be defined, 
Follow up returned to same operator, 
Primary and secondary keys for violation han- 
dling, 40 
In addition to traditional caseload divisions, in- 
cident handling can be defined for specialized 
populations within a given caseload, 
Notification handling rules, 
Notification method, 45 
Notification times and days, 
Random and scheduled calling services. 

[0038] For individuals not on RF monitoring or subject 
to other periodic monitoring, the system queues up calls 50 
to be placed based on the individual's schedule. Calls 
are presented to the appropriate operator for implemen- 
tation and handling. The results of the telephone call is 
then entered into the system database by the operator. 
This information, as well as all information in the data 55 
base, is available on-line to the systems for utilization in 
rule based processing and to each operator. 
[0039] Before gathered data can be assimilated into 



the data base, it must be standardized. The Communi- 
cation/Interpretation services provide the data manipu- 
lation so that data can be received from a variety of 
sources, including differing equipment and alternative 
input means. Interpretation services deal with a data 
"slug"; that is normalized in the following manner, as il- 
lustrated in Figure 1. The pre-normalized data string 
may look like this: 

nnnnnn hhmm yyyymmdd hhmm yyyymmdd xx 
nnnnnn represents the unit number 
hhmm represents time 
yyyymmdd represents date 
xx represents an event code 

In the exemplary embodiment, the first time and date 
(hhmm yyyymmdd) are the time and date the message 
was received by the host while the second, and subse- 
quent, represent the time and date of each event com- 
municated. The first twenty bytes are header informa- 
tion, common to all events contained in the data slug. 
[0040] This standard can be sub-classed for different 
equipment types to account for larger unit numbers, sec- 
ondary event codes, possible inclusion of a transmitter 
ID, etc. AQs illustrated in Figure 2, the communication 
service 20 will be responsible for receiving the data from 
the data collection equipment 2 1 and formatting the slug 
and passing it to the interpretation service 22. 

Gatekeeper services 

[0041] Gatekeeper services 23 monitor "events" that 
are the result of not receiving a message that was ex- 
pected. Examples include failure to return to a designat- 
ed location within a specified time period, failure to leave 
on time, a failure to receive an expected status check 
within a specified time period, and the like. The gate- 
keeper 23 polls the data set at predesignated times to 
determine the status of anticipated events 24. If the 
polled data indicates that the anticipated event has oc- 
curred, "no incident" is recorded 25 and returned to the 
system 26. In the event that the data indicates that an 
anticipated event has not occurred 27, an "incident" is 
recorded and reported back to the system 26 been re- 
ceived 

E-mail and facsimile services 

[0042] E-mail services and facsimile services are al- 
ternative means of delivery for information of a certain 
class to be transmitted. They must be available to the 
operator interface as selectable choices for output of re- 
porting (in addition to Print, Preview, and Disk). Upon 
selection a dialog box will prompt for facsimile number 
or e-mail address. Once selected, control should be re- 
turned to the operator. This is either background facsim- 
ile/e-mail or through the use of an ActiveX server on the 
network. In addition, both services must be capable of 



25 



30 



35 



40 



45 



50 



6 



11 



EP1 145 163 B1 



12 



automatic generation and delivery of specified docu- 
ments at pre-arranged times, or in regularly specified 
intervals. 

Voice services 

[0043] Voice services, Figure 3, are primarily used for 
sending program calls to the remote units. In addition 
they can be used to intercept operator involvement in 
the early verification phases of events 31 that can be 
resolved by the individual or other personnel at the data 
gathering location. Such events may include loss of 
power, missing status calls, short duration leaves, etc. 
[0044] When an "incident" is generated, for example 
by the gatekeeper 23 as described above, if the incident 
is of a predetermined class, the automated voice con- 
firmation service 31 is accessed. A call is placed, by 
voice or modem as appropriate to the data collection lo- 
cation following a pre-defined time delay after the inci- 
dent is reported, and the incident source is contacted 
32. If the call is answered, a audible message may be 
played or a data packet sent by modem to determine 
the situation status and potentially seeking correction. 
The system then waits for a response to the query 33. 
If the system receives a response that the incident is 
corrected 34, the incident status is revised and recorded 
35 back to the system 26 data base. If the call is not 
answered the incident status is updated to record the 
attempted resolution and failure and the data is record- 
ed back to the system data base 35. if the call is an- 
swered and the incident remains uncorrected, another 
delay is started 37 to determine if the situation gets re- 
solved within a specified time interval. Resolution or fail- 
ure is then recorded back to the system data base 35. 
These services can be activated and deactivated on a 
caseload basis to assist in a decrease in operator load 
when desirable and to allow for increased operator di- 
rect involvement when available. 

Backup and off-site monitoring services 

[0045] Automatic timed backup of data tables to spec- 
ified locations either on or off site. Backup cannot re- 
quire system shutdown. 

Security and auditing services 

[0046] In the exemplary embodiment illustrated, ab- 
stract security object can be created at login. This will 
permit increasing levels of table and field level security 
as the need develops. A method of the security object 
will return permissions when called if none are defined 
a default response will be returned. A transaction log will 
keep track of all changes, and fields in each table. The 
log will time, date, and identify the last change made to 
that record. 



Watchdog service 

[0047] Watchdog services make sure that none of the 
unattended slave systems fail without notification. Cur- 
5 rently data is being written to tables on a regular interval, 
this is monitored. This ensures that the watchdog will 
bark even if something other than the application causes 
a problem. 



[0048] The data base of the exemplary embodiment 
of the system of the present invention tracks all current 
information relating to each of the individuals monitored 
15 by the system. The data base of the invention will con- 
tain the relevant and desired information about the spe- 
cific knowledge base of data gathered by the data ac- 
quisition tier of the system. The integrity and accuracy 
of the data base of information is important to the system 
20 because the rule based processing depends upon data 
accuracy not only for specific actions but also for adjust- 
ments made to the rules based upon the composition of 
the data set. The data base is therefore maintained by 
the system with internal monitoring, including update/ 
25 deletion triggers and referential integrity. 

Security and auditing 

[0049] The system is adapted for relatively easy ad- 
30 dition of new technologies. Common business rules are 
therefore be independent of equipment. Equipment 
should be registered with the system in a common reg- 
istry. Objects that deal with specific equipment or tech- 
nologies can be sub-classed to deal with equipment 
35 specific features. 

COMMON OBJECTS 

[0050] 

40 

Level 1 authority - Agency 
Properties 

Primary key 
45 Name 
Address 
City 

State/province 
Postal code 
50 Telephone number(s) 

Contact 

Special instructions 

Force linkage between level 2 and 3 authorities? 
55 Level 2 authority - District 
Properties 

Primary key 
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Level 1 authority key 

Name 

Address 

City 

State/province 
Postal code 
Telephone number(s) 
Contact 

Time zone relative to host 

Level 3 authority - Officer 
Properties 

Primary key 

Level 1 authority key 

Level 2 authority key (if forced) 

Name 

Address 

City 

State/province 

Postal code 

Telephone number(s) 

Office 

Cellular 

Home 

Pager 

Contact 

Monitored Individual 
Properties 
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15 



20 



25 



30 



Primary key 
Level 3 authority key 
Level 2 authority key 
Level 1 authority key 
System type 

Number of units assigned to individual 
Unit number (for identification) 
Transmitter ID 
Transmitter timeout 
Sanity call interval 
Name 
Address 
City/town 
County 
State/province 
Postal code 
Phone number(s) 

Agency assigned case number/DOC number 

Government ID Social Security number so 

Time zone relative to host 

Alternate locations 

Race 

Sex 

Marital status 55 
Height and weight 
Date of birth 
Eye and hair color 



35 



40 



45 



Picture 

Notification priority 
Current status 
Term on ED 
Start date 
Termination date 
Reason for termination 
Type of monitoring 
Offense 

Specialized caseload/program 
Special instructions 

Curfews 
Properties 

Day of week 
Number in the day 
Date range curfew active 
Leave time 
Enter time 
Offender 

Date/time of last change 

Equipment 
Properties 

Unit number 

System type 

Serial number 

Transmitter ID 

Sanity call interval 

Assigned to client? 

Tamper Receiver and Transmitter 

TX in range 

AC present 

Time zone relative to host 

Battery condition Receiver and Transmitter 

Transmitter timeout 

Slug raw data communicated by the unit. May 
be 

pre-processed by the ComServer. 

Properties 

Unit number 

Unit assigned 

Time received 

Date received 

System type 

Transmitter ID 

Number of events contained 

Event information 

Event represents a single reportable event 
owned by 
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Slug 

Properties 

Time of event 
Date of event 
Type of event 

Incident - an event or events defined by the 

processing rules as an incident. 

Properties 
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Time of event 
Date of event 

Type of event 15 
Type of incident 

Controlling authority Level 1 to 3 authority, of- 
fender, caseload, etc. 
Activation time and date 

Follow up method 20 

Method(s) of reporting and time to report 

Print 

Facsimile 
Page 

Telephone call 25 
E-mail 

Staff handling incident 

Was incident handled? When? 



Unit assigned 
Transmitter tamper status 
Receiver tamper status 
Transmitter in range 
A/C Power 

Receiver battery status 

Transmitter battery status 

Transmitter timeout 

Offender out past curfew 

Time and date offender became out past curfew 

SERVICE SPECIFIC OBJECTS 
Properties 

Default sanity call interval 
Debug level 

Number of channels available 
Number of registered systems 
Array of registered systems 

GateKeeper- monitors non-communication events 
Properties 

Number of registered systems 
Array of registered systems 
Callback grace time 
Missed sanity call reminder 
Unit assigned 



Transaction - this is any event, incident, change, 

etc. completed in the system. 

Properties 

Transaction type 
Staff ID 
Offender ID 
Time of transaction 
Date of transaction 
Unit number if applicable 
Transmitter ID if applicable 

Security - allows unique definition of permissions 
Properties 

Operator ID 

Incident handling preference 
Array of permissions 



Last Message 
last contact 
Properties 



• status of equipment/offender as of 



Unit number 
Offender key 

Time and date of last report 
Time and date of next sanity call 
Time and date of next curfew 
Time and date of last movement 



30 



35 



40 



45 



50 



55 



Other features: 
Low level supervision 
Fee collection 
Drug/alcohol monitoring 

The incident server of the exemplary embodiment 
of the present invention handles all of the following 
functions: 

Watchdog 

Timing out of possible violations 
Activating violations for operator handling 
Auto paging of selected violations 
Processing results of voice calls 
Printing of incidents automatically or on-de- 
mand 

Queuing up voice calls for random contact 

In alternative embodiments, the functions of the incident 
service can be separated into several different compo- 
nents. 

Watchdog service: 

[0051] The watchdog service will be a separate COM/ 
DCOM component that will warn of any unattended 
service which has faltered. For communication servers, 
the system can falter due to telephone service interrup- 
tion or process termination within certain limits, without 
the generation of an incident. In one embodiment, the 
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watchdog checks the time and date stamp on the raw 
data file, xxx_DATA.DBF, to see if it has been updated 
within a pre-determined time interval. The time interval 
is based on the caseload of active units in the field and 
is recalculated on a periodic basis. The watchdog cur- 
rently barks by sounding the bell on the incident server 
and prints a message to the incident server screen. 
[0052] Other unattended servers are checked by re- 
ferring to the time and date stamp on a watchdog table. 
This table contains only one record which is updated on 
every cycle of the unattended server. An entry in an .INI 
file determines the maximum interval permitted between 
updates. 

[0053] An alternative watchdog service requires that 
each component to be watched must first register with 
the watchdog. Registration will include an identification 
key, and time in delta minutes. If the service is currently 
registered, registration will simply update the informa- 
tion. When a service is terminated manually, it will un- 
register with the watchdog. 

[0054] During normal operation the service will con- 
tinue to "ping" the watchdog with the identification key 
and the delta minutes. The "ping" is the same as regis- 
tration to the watched service. The watchdog considers 
a "ping" as a registration only if the service is not cur- 
rently registered. 

[0055] A second component associated with the 
watchdog is a watchdog output module. This will also 
register with the watchdog to receive any watchdog 
warnings. All computers on the network can register for 
watchdog output, or simply operator workstations. This 
will eliminate the need for the incident server to be phys- 
ically located near the operators who need to be warned 
of hosted systems. 

[0056] The watchdog system will use the ActiveX tim- 
er control developed for this application. Whenever a 
watchdog is not actually "barking" there will be almost 
no processor overhead for supporting the service. 
Watchdog API includes the following exposed methods: 

FeedTheDog(nProcesslD, nDeltaMinutes) 

RegisterMonitor(cProglD) 

UnRegisterMonitor(cProglD) 

RegisterTimer(cProglD,nProcesslD) 

UnRegisterTimer(cProglD) 

The Service ID could include some means of distin- 
guishing between an output and watched service. The 
watchdog services can be written in VC++. 

Gatekeeper Service: 

[0057] The Gatekeeper service provides alarm gen- 
eration on "non-event events". Examples include OUT 
PAST A SET TIME and MISSING STATUS CHECK. 
These are events that are the result of not receiving an- 
ticipated data from a monitoring unit. In one exemplary 
embodiment, gatekeeper methods required checking 



for these events by periodically polling the last message 
table for each registered ComServer. Each table must 
be polled separately for each event, often resulting in 
multiple polling. 

5 [0058] The system of a second exemplary embodi- 
ment of the present invention avoids the polling. This 
will increase the scalability by not having to dedicate a 
processor to this periodic polling. The gatekeeper is a 
communication server that monitors timer events rather 

10 than communication ports. It will invoke an instance of 
the standard Database Server and pass it "gatekeeper 
events" as they time out. 

[0059] The Gatekeeper of the present invention utiliz- 
es the services of the watchdog timer, described above, 

15 to alert it when a out of time or missed status event oc- 
curs. On startup, the Gatekeeper initializes the Data- 
base Server and registers with it. The Database Server 
then checks ail registered last message tables and de- 
termines the next time for a Gatekeeper event. It will reg- 

20 ister each time with the Gatekeeper as a Process ID 
(representing system type and event type), the number 
of minutes before timing out, and the Unit Number as- 
sociated with this event. 

[0060] Each database server will call a method in the 

25 Gatekeeper every time it processes a message. The da- 
tabase server will pass the appropriate Process ID, unit 
number, and the delta minutes it has stored in the last 
message table for this unit. If this time is earlier than the 
one that the Gatekeeper has stored for this Process ID, 

30 the Gatekeeper will call the watchdog and update it. If 
the unit number and Process ID match and the delta 
minutes is greater than that being stored, the timer will 
be stopped and the database server will be consulted 
to find the new next event and the watchdog will be fed. 

35 Otherwise the Gatekeeper will simply ignore the report. 
[0061] When the watchdog times out a Gatekeeper 
event, it calls a process method in the Gatekeeper. The 
Gatekeeper then executes the appropriate method in 
the database server to process this and other events 

40 that may be queued up for the same time. 

[0062] The Gatekeeper API will have the following 
methods exposed to the database servers: 

RegisterEvent(nProcesslD, nDeltaMinutes, nU- 
nitNumber) 

45 [0063] The database server will support the following 
exposed methods for the Gatekeeper: 

Register(cProcessName, nServerType, nChan- 
nels): 

so The Gatekeeper will only need to pass the cProc- 
essName parameter the other parameters are spe- 
cific to the communication servers. 
UnRegister(cProcessName, nServerType) 
GateKeeperEvent(nProcesslD) 

55 

Incident Service: 

[0064] The current incident server references a daily 
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incident table, VIO_mmdd.DBF where "mm" represents 
the month and "dd" represents the day. This table is pe- 
riodically polled (for example, every 15 seconds) to de- 
termine if there is any action to take. Actions performed 
by the Incident Server during polling include: 

Setting time for violations to become active 
Clearing violations that are not to be acted upon 
Activating violations at the assigned time 
Producing follow-up events such as printing, pag- 
ing, or facsimile. 

[0065] These events are all triggered by flags in the 
incident table that are set either by the incident server 
or other modules that handle one or another aspect of 
incident processing (e.g., ComServers, Operator Inter- 
face). The incident service of a second exemplary em- 
bodiment will do away with the periodic polling by sub- 
stituting the strategy employed by the watchdog service, 
using the Watchdog timer control and the Gatekeeper 
COM component to kick off the incident processing. 
[0066] The "Incident Server" of the first exemplary 
embodiment is contained in the Gatekeeper component 
and the Database Server. Incident and Gatekeeper 
modules can be run separately or as part of the same 
component depending upon caseload. At launch the 
component will be informed whether it is the Gatekeep- 
er, Incident Server, or both. As the Gatekeeper has al- 
ready been defined, we will only discuss the incident 
server component here. 

[0067] The Incident Server will utilize the services of 
the watchdog timer, described above, to alert it when a 
incident needs attention. On startup, the Incident Server 
initializes the Database Server and registers with it. The 
Database Server will then check the appropriate inci- 
dent table and determine the next time for a incident 
event. It will register this time with the Incident Server 
as a Process ID, the number of minutes before timing 
out, and the Unit Number associated with this event. 
[0068] Every time a incident is placed into the incident 
table, the Database Server will feed the Gatekeeper a 
process ID and a zero time. This will cause the Gate- 
keeper to immediately process a ServerEvent in its in- 
stance of the Database Server. 

Incident Handling: 

Routing: 

[0069] Skills based routing involves presenting a inci- 
dent to an operator that is best equipped to handle it. 
This could include facility with a foreign language, pre- 
vious handling of similar incidents from a specific indi- 
vidual, previous handling of other incidents from a spe- 
cific individual, or experience with a particular caseload. 
[0070] Least busy routing involves presenting a inci- 
dent to the operator who has the fewest incidents in their 
queue or who has handled the fewest incidents. 



Handling: 

[0071] Priority handling presents incidents to opera- 
tors in an order determined by the seriousness of the 
5 incident matched with the experience and/or skills of the 
operator. This requires that management clearly priori- 
tize incidents, individuals and operators for such han- 
dling. 

[0072] Timed handling presents incidents in the order 

10 they were received and/or occurred. 

[0073] Generally with a routing strategy the operator 
would be presented with only one incident on the 
screen. The incident presented would be determined by 
the routing and/or handling strategy. Experience sug- 

15 gests that denying operators the ability to select from 
among all pending alarms can cause problems, as man- 
agement cannot conceivably determine all possible 
contingencies and codify them. Therefore, the present 
invention addresses the problem of how to present op- 

20 erators with enough information to make some intelli- 
gent decisions on processing incidents while at the 
same time highlighting incidents or individuals that man- 
agement has targeted for specialized handling. 
[0074] To address this, the incident handler of the sec- 

25 ond exemplary embodiment presents all active inci- 
dents to all registered operators, but will prioritize them 
according to a operator profile. In addition, the interface 
will permit the operator to re-order the display in a man- 
ner similar to the Windows Explorer, grouping incidents 

30 together by offender, incident type, priority level, or 
caseload. 

Operator Profiles: 

35 [0075] The system administrator will assign each au- 
thorized operator an "operator profile". A default profile 
will be built on system installation. The profile will consist 
of up to 32 attributes that can be defined by the system 
administrator. If no attributes are defined, or if no indi- 

40 vidual operator profiles are entered, system defaults will 
be used. Each attribute has only two possible values 
and will be assigned a value of 0 for TRUE or 1 for 
FALSE. Examples of attributes could be knowledge of 
a specific foreign language, experience with certain 

45 caseloads, supervisory status, etc. The array of attribute 
values will compose a single 32-bit DWORD value that 
will uniquely identify a operator's permanent profile. 
[0076] This permanent "profile" will be passed to a 
"profile administrator" component when the operator 

50 logs onto the incident-processing screen and will return 
to the operator an "active profile". The active profile will 
determine how incidents are ordered and colored on the 
operator's screen. The purpose of the profile adminis- 
trator is simply to ensure that the operators currently 

55 logged into the system cover all attributes. For example, 
if only one operator is logged into the system, that op- 
erator will inherit all operator attributes and incidents will 
be ordered by priority and/or time activated. 
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[0077] Because many varying and different embodi- 
ments may be made within the scope of the inventive 
concept herein taught, and because many modifications 
may be made in the embodiments herein detailed in ac- 
cordance with the descriptive requirements of the law, 
it is to be understood that the details herein are to be 
interpreted as illustrative and not in a limiting sense. 



Claims 

1 . A data and object monitoring and response system 
with a three tier infrastructure for optimization of in- 
teroperability and task specific adaptability, com- 
prising: 

a data acquisition and communication tier; 
a data processing tier; and 
a user interface tier 

said data acquisition tier assimilating, and com- 
municating said acquired data; and 
said data precessing tier having a data receiv- 
ing component for receiving said communicat- 
ed data from said data acquisition tier, 

characterized in that said data processing 
tier includes: 

a comparative data base for comparing said ac- 
quired data to a predetermined set of anticipat- 
ed data; and 

a rule based data processing component for co- 
ordinated response to said acquired data, 
based upon said comparison. 

2. The system of claim 1, wherein said data acquisition 
and communication tier includes a plurality of dis- 
tributed data gathering units having non-common 
interface protocols for acquiring data. 

3. The system of claim 1 , wherein: 

said acquired data includes indicia of the 
source of said data and the time of acquisition; 
and 

said data base includes storage for a plurality 
of anticipated events corresponding to antici- 
pated acquired data, including the source and 
time of acquisition; 

said data base further including a flexible plu- 
rality of specified responses to the comparison 
of said indicia to said data base. 

4. The system of claim 5, wherein: 

said data base including a flexible formula for 
assignment of event response to one of a plu- 
rality of routes in said user interface tier. 



5. The system of claim 1 , wherein: 

. said data processing tier includes a gatekeeper 
for generation of an incident detection signal in 
5 response to the absence of one or more of said 

anticipated events within said established cri- 
teria. 

6. The system of claim 5, further including: 

10 

an incident discriminator for determination of 
routing of said incidents to said user interface 
tier. 

15 7. The system of claim 5, further including: 

an automated component for recontacting said 
data gathering source corresponding to said in- 
cident detection signal. 

20 

8. The system of claim 1 , wherein: 

said user interface tier includes a component 
for entry of anticipated data information. 

25 

9. The system of claim 1 , further including: 

a watchdog component for registration of said 
anticipated data information within said data 
30 processing tier, said watchdog monitoring said 

acquired data at intervals determined by said 
registered incidents for data corresponding to 
said anticipated data. 

35 10. The system of claim 8, 

said watchdog providing a notification signal to 
said gatekeeper for indication of said missed 
events. 

40 

11. The system of claim 1, wherein the first tier includes: 

a communication component for communicat- 
ing said acquired data. 

45 

12. A data and object monitoring and response system 
as claimed in claim 1 wherein said 

data acquisition and communication tier, in- 
50 eludes: 

a plurality of distributed data gathering 
units each having one or more interface 
protocols for acquiring data which includes 
55 indicia of the source of said data and the 

time of acquisition; 

a communication component for communi- 
cating said acquired data; and 
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a processor between said data gathering 
units and said communication component, 
for normalizing the data from said plurality 
of distributed data gathering units to pro- 
vide said indicia in a common format; 5 

said data processing tier, including: 



user interface components including 
user registration and access to said 
data base and to said acquired data; 
components for entry of anticipated 
event information; and 
components for user directed re- 
sponse to incidents. 



a data receiving component for receiving 
said communicated data from said data ac- 
quisition tier; 

a comparative data base with a set of an- 
ticipated data, said data base including: 

storage for a plurality of anticipated 
events corresponding to anticipated 
acquired data, including the source 
and time of acquisition; 
a flexible plurality of specified respons- 
es to the comparison of said indicia to 
said data base; 

a flexible formula for assignment of 
evant response to one of a plurality of 
routes in said user interface tier, for de- 
termination of routing of said events to 
said user interface tier said formula be- 
ing updated based upon acquired data 
and registered users; 
a rule based data processing compo- 
nent for comparing said acquired data 
with said predetermined set of antici- 
pated data and for coordinated re- 
sponse to said acquired data, based 
upon said comparison, including: 

a gatekeeper for generation of an 
incident detection signal in-re- 
sponse to the absence of one or 
more of said anticipated events 
within said established criteria; 
an automated component for re- 
contacting said data gathering 
source corresponding to said inci- 
dent detection signal; 
a watchdog component for regis- 
tration of said anticipated event in- 
formation, said watchdog monitor- 
ing said acquired data at intervals 
determined by said registered in- 
cidents for data corresponding to 
said anticipated events; 
said watchdog providing a notifi- 
cation signal to said gatekeeper 
for indication of said missed 
events 

said user interface tier, including: 



10 Pate ntansp ruche 

1. Daten- und Gegenstand-Uberwachungs- und Re- 
aktionssystem mit einer dreireihigen (three tier) In- 
frastruktur zum Optimieren einer Wechselbetreib- 
15 barkeit und aufgabenspezifischen Anpassbarkeit, 
umfassend: 

eine Datengewinnungs- und Kommunikations- 
ebene; 

20 eine Datenverarbeitungsebene; und 

eine Benutzerschnittstellenebene, 

wobei die Datengewinnungsebene die gewonne- 
nen Daten anpasst und kommuniziert; und 
25 die Datenverarbeitungsebene eine Datenemp- 
fangskomponente hat zum Empfangen derkommu- 
nizierten Daten von der Datenerfassungsebene 
her, 

dadurch gekennzeichnet, dass die Datenverar- 
30 beitungsebene beinhaltet: 

eine Vergleichsdatenbasis zum Vergleichen 
dergewonnenen Daten miteinem vorbestimm- 
ten Satz von antizipierten Daten; und 
35 eine auf einer Regel basierende Datenverar- 

beitungskomponente fur eine koordinierte Re- 
aktion auf die gewonnenen Daten auf der Basis 
des Vergleichs. 

40 2. System nach Anspruch 1 , wobei die Datengewin- 
nungs- und Kommunikationsebene eine Mehrzahl 
von verteilten Daten sammelnden Einheiten be- 
inhaltet, die nichtgemeinsame Schnittstellenproto- 
kolle zum Gewinnen von Daten haben. 



45 



50 



55 



3. System nach Anspruch 1, wobei: 

die gewonnenen Daten Hinweise auf die Quelle 
der Daten und die Zeit der Gewinnung beinhal- 
ten; und 

die Datenbank das Speichern fur eine Mehr- 
zahl von antizipierten Ereignissen entspre- 
chend antizipierter gewonnener Daten beinhal- 
tet, einschlie&lich der Quelle und Zeit der Ge- 
winnung; 

wobei die Datenbank weiterhin eine flexible Mehr- 
zahl von spezifizierten Reaktionen auf den Ver- 
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gleich der genannten Hinweise auf die Datenbank 
beinhaltet. 

4. System nach Anspruch 3, wobei: 

die Datenbank eine flexible Formel zur Zuord- 
nung von Ereignisreaktionen zu einer aus einer 
Mehrzahl von Routen in der Benutzer-Schnitt- 
stellenebene beinhaltet. 

5. System nach Anspruch 1, wobei: 

die Datenverarbeitungsebene einen Pfortner 
beinhaltet zum Erzeugen eines Vorfall-Detekti- 
onssignals in Reaktion auf die Abwesenheit ei- 
nes oder mehr der antizipierten Ereignisse in- 
nerhalb der festgesetzten Kriterien. 

6. System nach Anspruch 5, das weiterhin aufweist: 

einen Vorfall-Diskriminator zum Bestimmen 
des Routing der Vorfalle an die Benutzer- 
schnittstellenebene. 

7. System nach Anspruch 5, das weiterhin beinhaltet: 

eine automatisierte Komponente zum Rekon- 
taktieren der Datensammelquelle entspre- 
chend des Vorfall-Detektionssignals. 

8. System nach Anspruch 1 , wobei: 

die Benutzerschnittstellenebene eine Kompo- 
nente fur den Eintrag von antizipierten Daten- 
informationen beinhaltet. 

9. System nach Anspruch 1, das weiterhin umfasst: 

eine Uberwacherkomponente zum Registrie- 
ren der antizipierten Dateninformationen in der 
Datenverarbeitungsebene, wobei der Uberwa- 
cherdiegewonnenen Daten in Intervallenuber- 
wacht, die von den registrierten Vorfallen fur 
Daten entsprechend der antizipierten Daten 
bestimmt sind. 

10. System nach Anspruch 8, wobei der Uberwacher 
ein Benachrichtigungssignal an den Pfortner bereit- 
stellt, urn die versaumten Ereignisse anzuzeigen. 

11. System nach Anspruch 1, wobei die erste Ebene 
beinhaltet: 

eine Kommunikationskomponente zum Kom- 
munizieren der gewonnenen Daten. 

12. Daten- und Gegenstand-Uberwachungs- und Re- 
aktionssystem nach Anspruch 1, wobei 



die Datengewinnungs- und Kommunikationsebene 
beinhaltet: 

eine Mehrzahl vonverteilten Datensammelein- 
5 heiten, die jeweils eine oder mehr Schnittstel- 

lenprotokolle haben zum Gewinnen von Daten, 
die Hinweise auf die Quelle der Daten und Zeit 
der Gewinnung beinhalten; 
eine Kommunikationskomponente zum Kom- 
io munizieren der gewonnenen Daten; und 

einen Prozessor zwischen den Datensammel- 
einheiten und der Kommunikationskomponen- 
te zum Normalisieren der Daten von der Mehr- 
zahl von verteilte Daten sammelnden Einheiten 
is zum Bereitstellen der Hinweise in einem ge- 

meinsamen Format; 

wobei die Datenverarbeitungsebene beinhaltet: 

20 eine Datenempfangskomponente zum Emp- 

fangen der kommunizierten Daten von der Da- 
tengewinnungsebene; 

eine Vergleichsdatenbasis mit einem Satz von 
antizipierten Daten, wobei die Datenbank be- 
25 inhaltet: 

einen Speicher fur eine Mehrzahl von anti- 
zipierten Ereignissen entsprechend antizi- 
pierten gewonnenen Daten einschliefllich 
30 der Quelle und Zeit der Gewinnung; 

eine flexible Mehrzahl von spezifizierten 
Reaktionen auf den Vergleich der Hinwei- 
se auf die Datenbank; 
eine flexible Formel fur die Zuordnung ei- 
35 ner Ereignisreaktion auf eine einer Mehr- 

zahl von Routen in der Benutzerschnittstel- 
lenebene zum Bestimmen des Routing der 
Ereignisse zu der Benutzerschnittstellen- 
ebene, wobei die Formel auf der Basis von 
40 gewonnenen Daten und registrierten Be- 

nutzern aktualisiert wird; 

eine auf einer Regel basierende Datenverar- 
beitungskomponente zum Vergleichen der ge- 
45 wonnenen Daten mit dem vorbestimmten Satz 

der antizipierten Daten und fur eine koordinier- 
te Reaktion auf die gewonnenen Daten auf der 
Basis des Vergleichs mit: 

50 einem Pfortner zum Erzeugen eines Vor- 

fall-Detektionssignals in Reaktion auf die 
Abwesenheit eines oder mehr der antizi- 
pierten Ereignisse innerhalb der festge- 
setzten Kriterien; 
55 einer automatisierten Komponente zum 

Rekontaktieren der Datensammelquelle 
entsprechend dem Vorfall-Detektions- 
slgnal; 
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einer Uberwacherkomponente zum Regi- 
strieren der antizipierten Ereignisinforma- 
tion, wobei der Uberwacher die gewonne- 
nen Daten in Intervallen uberwacht, die 
von den registrierten Vorfallen fur Daten 5 
entsprechend der antizipierten Ereignisse 
bestimmt werden; 

wobei der Uberwacher ein Benachrichti- 
gungssignal an den Pfortner liefert zur Anzeige der 10 
versaumten Ereignisse, 

wobei die Benutzerschnittstellenebene umfasst: 

Benutzerschnittstellenkomponenten einschlieft- 
lich Benutzerregistrierung und Zugriff auf die Da- * 5 
tenbank und die erfassten Daten; 
Komponenten zur Eingabe antizipierter Ereig- 
nisinformationen; und 

Komponenten fur eine benutzergerichtete Re- 
aktion auf Ereignisse. 20 



Revendications 

1. Systeme de controle de donnees et d'objets et de 25 
reponse ayant une infrastructure a trois etages pour 
I'optimisation de rinteroperabilite etde I'adaptabilite 

a des taches specifiques, comportant : 

un etage d'acquisition et de communication de 30 
donnees, 

un etage de traitement de donnees, et 

un etage d'interface-utilisateur, 

(edit etage d'acquisition de donnees assimitant 

et communiquant lesdites donnees acquises, 35 

et 

ledit etage de traitement de donnees ayant un 
composant de reception de donnees pour re- 
cevoir lesdites donnees communiquees en pro- 
venance dudit etage d'acquisition de donnees, *o 

caracterise en ce que ledit etage de traitement de 
donnees inclut : 

une base de donnees comparative pour com- 45 
parer lesdites donnees acquises a un ensem- 
ble predetermine de donnees anticipees, et 
un composant de traitement de donnees a base 
de regies pour fournir la n§ponse coordonnee 
auxdites donnees acquises, sur la base de la- so 
dite comparaison. 

2. Systeme selon la revendication 1 , dans lequel ledit 
etage d'acquisition et de communication de don- 
nees inclut une pluralite d'unites d'assemblage de 55 
donnees reparties ayant des protocoles d'interface 
non-communs pour acquerir des donnees. 



3. Systeme selon la revendication 1, dans lequel : 

lesdites donnees acquises incluent I'indice de 
la source desdites donnees et I'instant d'acqui- 
sition, et 

ladite base de donnees inclut la memorisation 
d'une pluralite d'evenements anticipes corres- 
pondant a des donnees acquises anticipees, y 
compris la source et Tinstant d'acquisition, 
ladite base de donnees inclut en outre une plu- 
ralite souple de reponses specifiers a la com- 
paraison dudit indice a ladite base de donnees. 

4. Systeme selon la revendication 3, dans lequel : 

ladite base de donnees inclut une formule sou- 
ple pour I'attribution d'une reponse d'evene- 
ment a un itineraire parmi une pluralite d'itine- 
raires dans ledit etage d'interface-utilisateur. 

5. Systeme selon la revendication 1 , dans lequel : 

ledit etage de traitement de donnees inclut un 
garde-barriere pour la generation d'un signal 
de detection d'incident en r6ponse a I'absence 
d'un ou de plusieurs evenements parmi lesdits 
evenements anticipes selon ledit critere etabli. 

6. Systeme selon la revendication 5, incluant en 
outre : 

un discriminateur d'incidents pour ia determi- 
nation de I'acheminement desdits incidents 
vers ledit etage d'interface-utilisateur. 

7. Systeme selon la revendication 5, incluant en 
outre : 

un composant automatise pour recontacter la- 
dite source d'assemblage de donnees corres- 
pondent audit signal de detection d'incident. 

8. Systeme selon la revendication 1 , dans lequel : 

ledit etage d'interface-utilisateur inclut un com- 
posant pour I'entree d'informations de donnees 
anticipees. 

9. Systeme selon la revendication 1, incluant en 
outre : 

un composant de surveillance pour I'enregis- 
trement desdites informations de donnees an- 
ticipees dans ledit etage de traitement de don- 
nees, ledit composant de surveillance contro- 
lant lesdites donnees acquises a intervalles de- 
termines par lesdits incidents enregistres se 
rapportant a des donn§es correspondant 
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auxdites donnees anticipees. 

10. Systeme sefon la revendication 8, dans lequel 

(edit composant de surveillance fournit un si- 
gnal de notification audit garde-barriere pour I'indi- 
cation desdits evenements manques. 

11. Systeme selon la revendication 1, dans lequel le 
premier etage inclut: 

un composant de communication pour commu- 
niquer lesdites donnees acquises. 

12. Systeme de controle de donnees et d'objets et de 
reponse selon la revendication 1, dans lequel 

ledit etage d'acquisition et de communication 
de donnees inclut : 

une pluralite d'unites d'assemblage de don- 
nees reparties chacune ayant un ou plusieurs 
protocoles d'interface pour acquerir des don- 
nees qui incluent I'indice de la source desdites 
donnees et ['instant d'acquisition, 
un composant de communication pour commu- 
niquer lesdites donnees acquises, et 
un processeur entre lesdites unites d'assem- 
blage de donnees et ledit composant de com- 
munication, pour normaliser les donnees pro- 
venant de ladite pluralite d'unites d'assemblage 
de donnees reparties pour fournir ledit indice 
dans un format commun, 

ledit etage de traitement de donnees inclut : 

un composant de reception de donnees pour 
recevoir lesdites donnees communiquees par 
ledit etage d'acquisition de donnees, 
une base de donnees de comparaison a un en- 
semble de donnees anticipees, ladite base de 
donnees incluant : 
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base de regies pour comparer lesdites 
donnees acquises audit ensemble prede- 
termine de donnees anticipees et pour 
fournir une reponse coordonnee auxdites 
donnees acquises, sur la base de ladite 
comparaison, incluant : 

un garde-barriere pour la generation 
d'un signal de detection d'incident en 
reponse a ('absence d'un ou de plu- 
sieurs desdits evenements anticipes 
selon ledit critere etabli, 
un composant automatise pour recon- 
tacter ladite source d'assemblage de 
donnees correspondant audit signal 
de detection d'incident, 
un composant de surveillance pour 
I'enregistrement desdites informations 
d'evenements anticipes, ledit compo- 
sant de surveillance controlant lesdi- 
tes donnees acquises a intervalles de- 
termines par lesdits incidents enregis- 
tres se rapportant a des donnees cor- 
respondant auxdits evenements anti- 
cipes, 

ledit composant de surveillance four- 
nissant un signal de notification audit 
garde-barriere pour I'indication desdits 
evenements manques, 

ledit etage d'interface-utilisateur inclut : 

des composants d'interface-utilisateur incluant 
I'enregistrement des utilisateurs et I'acces des 
utilisateurs a ladite base de donnees et auxdi- 
tes donnees acquises, 

des composants pour I'entree d'informations 
d'evenements anticipes, et 
des composants pour fournir une reponse a 
des incidents adressee aux utilisateurs. 



la memorisation d'une pluralite d'evene- 
ments anticipes correspondant a des don- 
nees acquises anticipees, y compris la 
source et I'instant d'acquisition, 
une pluralite souple de reponses speci- 
fies a la comparaison dudit indice a ladite 
base de donnees, 

une formule souple pour I'attribution d'une 
reponse d'evenement a un itineraire parmi so 
une pluralite d'itineraires dans ledit etage 
d'interface-utilisateur, pour la determina- 
tion de I'acheminement desdits evene- 
ments vers ledit etage d'interface-utilisa- 
teur, ladite formule etant mise a jour sur la 55 
base des donnees acquises et des utilisa- 
teurs enregistres, 

un composant de traitement de donnees a 
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